Some file systems support a single stand alone computer. Other file systems support multiple computers over a network. While race conditions may exist for a file system supporting a single stand alone computer, it is more likely that race conditions may exist when a file system supports multiple computers at the same time.
StorNext is a shared disk file system that may support multiple computers and processes at the same time. StorNext Storage Manager is a hierarchical storage management system. StorNext and the StorNext Storage Manager have worked together to facilitate numerous applications and to support numerous different environments. However, during these interactions a race condition may have arisen that could potentially lead to inconsistent states between clients (e.g., StorNext front end) and servers (e.g., StorNext back end).
More generally, shared storage device file systems with client server architectures that perform multi-step stateful operations may have their consistency depend on the successful avoidance of the consequences of race conditions.
The StorNext File System is a shared disk file system. StorNext is provided by Quantum Corporation. StorNext is installed on hosts that are connected to the same disk array in a storage area network (SAN). Client systems do not have to run the same operating system to access a StorNext shared file system. In some examples, StorNext facilitates producing environments that include, but are not limited to, an environment where large files (e.g., satellite image data) are shared by users without network delays, and an environment where a file is made available for access by multiple readers starting at different times (e.g., on-demand movie).
The StorNext file system supports Quantum's StorNext Storage Manager. Storage Manager is a hierarchical storage management system that is used for data archival with a back end robotic tape library. StorNext data management software provides high-speed content sharing and cost-effective data archiving. StorNext facilitates building an infrastructure that consolidates resources so that workflow runs faster and operations cost less. StorNext offers data sharing and retention in a single solution. Even in heterogeneous environments, data is easily accessible to different hosts. SAN connectivity facilitates high performance while local area network (LAN) connectivity using clustered gateway systems facilitates cost efficiency and fan-out.
StorNext may run on many computers at the same time. StorNext front end clients may communicate with StorNext back end servers and server processes. The back end may include a server and a metadata controller. The metadata controller may manage information about files that are available to users of the shared disk file system. In one configuration, clients may be limited to reading files and writing files and thus may not be allowed to create files on their own behalf. Instead, clients may rely on a back end server or process to actually create a file. A client may request that a file be created by a back end server or process. In this application, terms including “actually create a file”, “fully created”, and “total file creation completion” refer to a state associated with the existence of a file on durable media.
Conventionally, a back end server or process may have been very aggressive in responding to the front end about partial completion of the file create so that the front end client does not have to wait too long to move on to its next task (e.g., writing the newly created file). This back end aggressiveness may lead to a condition where the back end has reported to a front end that a file has been created when in fact the file has not yet been fully created. While this condition exists, the file may only exist as its metadata description in a volatile memory (e.g., back end random access memory (RAM)) at the back end. While this condition exists, a back end crash or other loss of state at the back end after reporting initial creation but before actually completing creation could yield inconsistent states between front end clients and back end servers. An inconsistent state could lead, for example, to a front end trying to read from or write to a file that doesn't actually exist. The condition may exist because the back end may create the file on behalf of the front end by establishing a metadata description in volatile memory and then scheduling the writing of the metadata to non-volatile memory for a later time.
To reduce the period of time during which a crash could yield the inconsistent state, the back end may be very aggressive in pushing metadata to disk to complete the file creation. However, very aggressive metadata pushing may introduce additional inefficiencies. For example, a less than block or page sized write may be performed, which can be very inefficient. Another conventional approach to minimizing the race condition was to force the front end to wait for the back end to actually create the file. This approach may be unacceptable when a large number of files are being created in a short period of time during, for example, a backup procedure.